home *** CD-ROM | disk | FTP | other *** search
- From: Ulrich Kuehn <kuehn@GOEDEL.UNI-MUENSTER.DE>
- Subject: Re: GEMDOS re-entrancy
- Date: Wed, 25 May 1994 10:09:46 +0200
-
- Hello!
-
- |>1) GEMDOS must be re-entrant. It isn't.
- |>
- To make it clear: meant is the GEMDOS in the ROM, which is used by MiNT
- as filesystem and as provider for some other I/O services, right?
-
- |>2) Process B must not make a GEMDOS call. This could lead to some weird
- |> multitasking. I guess it would work, but halting the AES when a program
- |> tries to load fonts could get kinda hairy. Processes that can't call
- |> GEMDOS cannot accept input or display output. This will work, but it's
- |> hairy.
- |>
- The AES does not make direct jumps into the GEMDOS in ROM, it goes via
- trap vector, so it will first run through the MiNT kernel. But for disk
- accesses, it will be blocked anyway, as there is no way to run two trans-
- fers simultaniously :)
- But all the other MiNT services which do not rely on the old GEMDOS are
- not affected.
-
- |>3) Make process A sleep OUTSIDE GEMDOS. There must be some way to clean up
- |> GEMDOS while process A sleeps, perhaps exiting GEMDOS and putting the
- |> process on some sort of wait queue. Then have the process re-enter
- |> GEMDOS when the IO is complete. There has GOT to be some way to clean
- |> things up.
- |>
- |>I'd rather make GEMDOS re-entrant, but failing that perhaps option 3 could
- |>be implemented?
- |>
- Sounds sort of difficult. Do you have the complete source of Gemdos? A
- better choice would be to have a tos xfs, then we get rid of a whole
- pile of problems at once. May be the linux sources can be modified
- easily?
-
- Regards,
- Ulrich
-
-